This disclosure relates generally to the field of computer network management. More particularly, but not by way of limitation, it relates to techniques for identifying and allocating resources to provision a specified service in a cloud computing environment.
The North American National Institute for Standard and Technology (NIST) describes cloud computing as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned with minimal management effort or service provider interaction. In many modern environments the implementation of a cloud may be conceptually divided into layers—where each layer can “talk” with only those layers directly above and below it (typically through Application Programming Interfaces or APIs). For example, The NIST describes three basic cloud model layers Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). in one cloud environment the user may interact with a workload manager (at the SaaS layer) in which services are defined (e.g., a shopping cart web application). Conceptually below this may be a PaaS layer in which a given resource (e.g., a compute cluster) is defined which, in truth, may be comprised of one or more elements from the IaaS layer (e.g., compute platforms or blades).
When provisioning a new cloud-based service, a user typically provides a set of resource requirements. The task is then to determine if the necessary resources are available and, if so, to allocate them so that the service may be provided. In the past, one of three approaches are adopted for this task: brute force; merging of architectural layers; and finding an optimal solution. In the brute-force approach, an assumption is made that the necessary resources are available. Under this assumption, each needed resource is identified and allocated in turn. A drawback to this approach is that if ‘N’ resources of a specified type are needed, but only (N-1) of those resources are actually available, the process fails on the attempted allocation of the Nth resource. At that time, all prior allocations must be undone. For complex services, this approach can be very time consumptive and, in addition, inefficient in its use of typing up resources that ultimately cannot be used. In an approach that merges the architectural layers of a cloud, a single layer gains visibility to all aspects of a service's topology. While this can work, and work efficiently, it results in an architecture that is rigid and inflexible. No architectural layer implementation may be changed without affecting all other layers. In an optimal solution approach, a function may be generated based on the required resources whereafter all suitable resources are identified through an investigation of each layer to identify all possible solutions to satisfy the target service request (i.e., the function). Once identified, all possible solutions are evaluated against a measurement metric and the “best” solution is chosen. A drawback to this approach is that it can be very time consumptive. For large systems (i.e., services requiring a number of different resources, some of which may be defined in terms of collections of other resources), the optimal solution may take an infinitely long time to identify.
Thus, it would be beneficial to provide a mechanism to identify those resources needed to satisfy a service request that is cost effective in terms of both time and resource use.